ÇEOÐAINT ÆILE ÆORMAT -------------------- BY ÂRUCE ÖRIELING (BVRIELING@UNDERGRAD.MATH.WATERLOO.EDU) ÇEOÐAINT IS AN EXCELLENT GRAPHICS PROGRAM WRITTEN FOR THE ÇÅÏÓ ENVIRONMENT. ÉTS DISK ACCESS IS RELATIVELY QUICK, COMPARED IT TO WHAT A COMPARABLE PROGRAM WOULD DO ON A NON-ÇÅÏÓ EQUIPPED Ã64. ÐART OF THIS ACCOMPLISHMENT CAN BE ATTRIBUTED TO THE DISKÔURBO THAT IS AN INTEGRAL PART OF ÇÅÏÓ. ÈOWEVER, THE SPECIAL ÇEOÐAINT FILE-SAVING SCHEME DESERVES SOME OF THE CREDIT. ÖÌÉÒ ---- ÇEOÐAINT FILES ARE ALWAYS STORED IN ÖARIABLE ÌENGTH ÉNDEXED ÒECORDING FILES. ÖÌÉÒ FILES OFFER ADVANTAGES NOT AVAILABLE WITHOUT ÇÅÏÓ. ÇENERALLY SPEAKING, ÖÌÉÒ IS THE ULTIMATE IN ÒÅÌÁÔÉÖÅ FILES. ÔHE FORMAT OF A ÖÌÉÒ FILE IS NOT THAT DIFFICULT TO FIGURE OUT. ×HILE IN A REGULAR Ã64 FILE, THE TWO BYTES DIRECTLY FOLLOWING THE ÆÉÌÅÔÙÐÅ BYTE IN THE DIRECTORY WOULD POINT TO THE DATA FILE FOLLOWING, ÖÌÉÒ FILES USE THESE TWO BYTES TO POINT TO A ÖÌÉÒ ÈÅÁÄÅÒ ÂÌÏÃË (DON'T CONFUSE THE ÖÌÉÒ ÈÅÁÄÅÒ BLOCK WITH THE ÉÎÆÏ BLOCK). ÔHE FIRST TWO BYTES OF THIS BLOCK ARE $00/ÆÆ, AS THE HEADER BLOCK IS A ÍÁØÉÍÕÍ OF ONE BLOCK LONG. (ÔHIS IS WHY WHEN YOU ÖÁÌÉÄÁÔÅ A ÇÅÏÓ DISK FROM Ã64 MODE, ÇEOÐAINT PICTURES ARE LOST. ÏNLY THE HEADER BLOCK IS RECOGNISED AS BEING PART OF THE FILE. ÔHE REST OF THE PICTURE GETS DEALLOCATED IN THE ÂÁÍ). ÔHE REMAINING 254 BYTES IN THE BLOCK ARE DIVIDED INTO 127 2-BYTE POINTERS TO TRACKS/SECTORS ON THE DISK. ÔHESE POINTERS POINT TO THE INDIVIDUAL RECORDS OF THE ÖÌÉÒ FILE, WHICH MAY BE ÁÎÙ NUMBER OF BLOCKS LONG. ÔHE ÖÌÉÒ TRACK/SECTOR POINTERS IN THE ÖÌÉÒ HEADER BLOCK ONLY POINT TO THE ÆÉÒÓÔ BLOCK OF THE CHAIN. ÆROM THEN ON, THE SECTORS CHAIN THEMSELVES TOGETHER USING THE NORMAL FORMAT IE. THE FIRST TWO BYTES OF EACH BLOCK POINT TO THE FOLLOWING BLOCK. Á SAMPLE ÇEOÐAINT ÖÌÉÒ HEADER MIGHT LOOK LIKE THIS: 0000:00 ÆÆ 03 11 03 05 03 01 ........ 0008:04 03 00 ÆÆ 00 ÆÆ 00 ÆÆ ........ 0010:04 07 00 00 00 00 00 00 ........ ETC.... ÔHE FIRST TWO BYTES, $00/ÆÆ, TELL THE DRIVE THAT THIS IS THE LAST (AND ONLY) BLOCK IN THIS ÖÌÉÒ ÈÅÁÄÅÒ ÓÅÃÔÉÏÎ (WILL NEVER BE MORE THAN 1 BLOCK, AS WAS MENTIONED EARLIER). ÔHE NEXT PAIR OF BYTES, $03/11, POINTS TO THE FIRST ÖÌÉÒ RECORD. ÔHE NEXT TWO, $03/05, POINT TO THE SECOND RECORD. ÙOU WILL NOTICE THAT 5TH RECORD CONTAINS THE VALUES $00/ÆÆ. ÔHIS MEANS THAT FOR THIS RECORD, THERE IS NO PICTURE DATA. ×E WILL GET INTO EXACTLY WHAT THE DATA HELD IN THE RECORDS MEAN IN A MINUTE. ÔHE $00/ÆÆ ENTRIES INDICATE AN EMPTY RECORD. ÆINALLY, THE 9TH ENTRY, $00/00 INDICATES THE END OF THE ÇEOÐAINT FILE. ÔHERE IS NO MORE DATA BEYOND THIS POINT. ÏNE NOTE SHOULD BE MADE. ÇEOÐAINT IS NOT ALWAYS CONSISTENT IN ITS HANDLING OF THE DATA IN A HEADER BLOCK. ÓOMETIMES, IT WILL SHOW QUITE A FEW $00/ÆÆ COMBINATIONS BEFORE FINALLY TERMINATING WITH A $00/00. ×HEN READING THE FILE, É ALWAYS READ THE ENTIRE HEADER, AS É DON'T TRUST THE END OF FILE METHOD MENTIONED ABOVE. ÊUST REMEMBER THAT ANY TRACK/SECTOR LINK THAT DOES NOT CONTAIN $00/ÆÆ OR $00/00 IS A VALID RECORD, WITH PICTURE DATA. ÌAYOUT ON ÓCREEN ---------------- ÇÅÏÓ ORIENTS THE DATA IN A ÇEOÐAINT FILE SLIGHTLY DIFFERENTLY THAN IN A ÐHOTOÓCRAP OR AN ÉCON. Á PHOTOSCRAP STORES THE BYTES CORROSPONDING TO A SCREEN WHICH LOOKS LIKE THIS: 001 002 003 004 005 ....0012 013 014 015 016 017 ....0024 ÃONSECUTIVE BYTES ARE PLACED ÂÅÓÉÄÅ EACH OTHER. ÈOWEVER, IF YOU ARE AT ALL FAMILIAR WITH THE LAYOUT OF A Ã64 HI-RES SCREEN, YOU WILL KNOW THIS IS VERY DIFFERENT FROM THE LAYOUT THAT THE ÖÉà CHIP SEES DATA. ÇEOÐAINT USES A FORMAT IDENTICAL TO THE ÖÉà CHIP LAYOUT ON SCREEN. ÇEOÐAINT PICTURES ARE STORED IN THE FOLLOWING FORMAT: 001 009 017 025 033 ..... 313 002 010 018 026 034 ..... 314 003 011 019 027 035 ..... 315 004 012 020 028 036 ..... 316 005 013 021 029 037 ..... 317 006 014 022 030 038 ..... 318 007 015 023 031 039 ..... 319 008 016 024 032 040 ..... 320 321 329 ..... 322 330 ..... 323 331 ..... 324 332 ..... 325 333 ..... 326 334 ..... 327 335 ..... 328 336 ..... ÁS YOU CAN SEE, THIS IS VERY DIFFERENT FROM THE ÐHOTOÓCRAP FORMAT. ÃONSECUTIVE BYTES ARE ÎÏÔ STORED ON THE SCREEN BESIDE EACH OTHER. ÒATHER, THEY ARE STORED UNDERNEATH EACH OTHER INTO GROUPS OF 8 BYTES. ÔHIS MAKES MOVING THE DATA FROM THE DISK ONTO THE SCREEN THAT MUCH FASTER, AS THE DECOMPACTED BYTES CAN JUST BE STORED ON THE SCREEN AFTER EACH OTHER. ÏF COURSE, THIS MAKES PORTING ÇÅÏÓ PICS TO THE 128'S ÖÄà THAT MUCH MORE DIFFICULT, AS THE ÖÄà CONFORMS TO THE ÐHOTOÓCRAP FORMAT. ÃOMPRESSION ÍETHOD ------------------ ÇÅÏÓ USES AN EXCELLENT COMPRESSION METHOD TO STORE FILES ON DISK. ÙOU MAY HAVE NOTICED THAT NEARLY EMPTY PICTURES ON DISK CONSUME VERY LITTLE DISK SPACE. ÔHIS CAN BE CREDITED TO ÇEOÐAINT'S SMART COMPRESSION TECHNIQUES. ÂASICALLY, THE FORMAT OF THE COMPRESSION HAS ONE ÃÏÍÍÁÎÄ BYTE FOLLOWED BY ONE OR MORE ÄÁÔÁ BYTES. ÔHE ÃÏÍÍÁÎÄ BYTE TELLS ÇÅÏÓ WHAT TO DO WITH FOLLOWING ÄÁÔÁ BYTES. ÔHERE ARE 4 COMMANDS FOR COMPRESSION: 1) ÉF THE ÃÏÍÍÁÎÄ BYTE IS LESS THAN 64, THIS INDICATES THAT THERE ARE 'ÃÏÍÍÁÎÄ' MANY ÄÁÔÁ BYTES FOLLOWING THAT ARE TO BE TAKEN AS INDIVIDUAL BYTES. ÔHIS IS THE LEAST EFFECTIVE METHOD OF COMPRESSION, AS NO COMPRESSION TAKES PLACE. 2) ÉF THE ÃÏÍÍÁÎÄ BYTE RANGES FROM 65 TO 127, THEN THIS IS A SPECIAL TYPE OF COMPRESSION. ÆIRST OF ALL, THE NEXT 8 BYTES IN THE FILE ARE READ IN AS ÄÁÔÁ. ÔHIS ÄÁÔÁ IS USED TO MAKE AN 8*8 'STAMP'. ÓECONDLY, THE AMOUNT OF TIMES TO 'STAMP' THIS 8*8 SQUARE IS CALCULATED (ÃÏÍÍÁÎÄ ÁÎÄ 63). ÔHEN, THE STAMPING IS DONE. 'ÓTAMPING' SOUNDS MORE DIFFICULT THAT IT REALLY IS. ×HAT IT BOILS DOWN TO, IS REPEATING THE 8 BYTE ÄÁÔÁ STAMP 'ÃÏÍÍÁÎÄ ÁÎÄ 63' TIMES. 3) ÉF THE ÃÏÍÍÁÎÄ BYTE IS 129 OR GREATER, THEN THE FOLLOWING ÄÁÔÁ BYTE IS REPEATED 'ÃÏÍÍÁÎÄ ÁÎÄ 127' TIMES. ÔHIS IS DIFFERENT FROM #1, AS ONLY 1 ÄÁÔÁ BYTE IS CALLED IN, AND SIMPLY REPEATED. #1 CALLED IN 'ÃÏÍÍÁÎÄ' MANY ÄÁÔÁ BYTES. 4) ÉF THE ÃÏÍÍÁÎÄ BYTE IS ÚÅÒÏ, WE HAVE REACHED THE END OF THE ÖÌÉÒ RECORD FOR THE ÇEOÐAINT PICTURE. ÉT SHOULD BE NOTED THAT THE ÃÏÍÍÁÎÄ BYTE WILL ÎÅÖÅÒ BE 64 OR 128. ÉF IT IS, THERE HAS BEEN AN ERROR. ÆORMAT OF ÄATA ÁFTER ÄECOMPACTING --------------------------------- ÁFTER THE DATA HAS BEEN DECOMPACTED, IT REMAINS TO BE PLACED ON THE SCREEN. ÅACH ÖÌÉÒ RECORD HOLDS 16 SCANLINES OF DATA, OR 2 CHARACTER LINES (DIFFERENT WAYS OF LOOKING AT THE SAME THING). ÔHE FORMAT OF THE DATA IS AS FOLLOWS: ÆIRST, THERE IS 640 BYTES OF PICTURE DATA, COMPRISING THE FIRST CHARACTER LINE (8 SCANLINES). ÒEMEMBER, ÇEOÐAINT PICTURES ARE 640 PIXELS ACROSS. 640 PIXELS WORKS OUT TO 80 BYTES. Á CHARACTER LINE IS 8 PIXELS DEEP, SO 80*8 COMES TO 640 BYTES. ÔHESE BYTES ARE FOLLOWED BY THE 640 BYTES FOR THE SECOND CHACACTER LINE (NEXT 8 SCANLINES). ÔHIS IS FOLLOWED BY 8 GARBAGE BYTES THAT ACCIDENTALY WORKED THEMSELVES INTO THE ORIGINAL ÇEOÐAINT DESIGN. ÔHEY SHOULD BE SET TO ZERO. ÆINALLY, TWO SETS OF 80 BYTES OF COLOUR DATA FOLLOW. ÔHE FIRST SET COMPRISES THE COLOUR FOR THE FIRST LINE, THE SECOND 80 BYTES FOR THE SECOND LINE. ÔO WRAP THINGS UP, THE ÖÌÉÒ RECORD IS TERMINATED BY A ZERO BYTE. ÔHE NEXT ÖÌÉÒ RECORD WILL HOLD THE DATA FOR THE ÎÅØÔ 16 SCANLINES, AND SO ON. ÃONCLUSION ---------- ÔHAT ABOUT WRAPS UP THIS DISCUSSION ON ÇEOÐAINT FORMAT FOR FILES. ×E'VE DISCUSSED THE FORMAT OF ÖÌÉÒ FILES ON DISK, LAYOUT OF PICTURE DATA ON SCREEN, COMPRESSION METHODS USED IN ÇEOÐAINT FILES, AND THE FORMAT OF THE DATA ONCE DECOMPACTED. É HOPE THIS INFORMATION WILL COME IN HANDY FOR SOMEONE. ============================================================================== ÒASTERS - ×HAT ÔHEY ÁRE AND ÈOW TO ÕSE ÔHEM BY ÂRUCE ÖRIELING - (BVRIELING@UNDERGRAD.MATH.WATERLOO.EDU) ÁNYONE WHO HAS FIDDLED AROUND WITH INTERRUPTS ON THE ÃOMMODORE 64 HAS UNDOUBTEDLY HEARD AT ONE TIME OR ANOTHER OF THE CONCEPT OF RASTERS BEING MENTIONED. ÒASTERS ARE THE 'ULTIMATE' ACHIEVEMENT OF INTERRUPT PROGRAMMING, OR SO THEY SAY. ×HAT IS A RASTER? ÁND HOW DOES ONE GO ABOUT WRITING A PROGRAM TO USE THEM? ÏVERVIEW OF WHAT ÉNTERRUPTS ARE ALL ABOUT ----------------------------------------- Á RASTER IS SORT FORM FOR THE CONCEPT OF A 'RASTER INTERRUPT'. ÂEFORE GOING INTO RASTERS, PERHAPS A BRIEF REVIEW OF INTERRUPTS IS IN ORDER. ÉNTERRUPTS ARE EVENTS GENERATED BY THE ÃÉÁ TIMER IN THE Ã64 TO PERFORM CERTAIN TASKS. 60 TIMES A SECOND, THE ÃÉÁ CHIP SIGNALS AN INTERRUPT IS DUE TO BE PROCESSED (IE. THE INTERRUPT TIMER TIMED OUT). ÔHIS CAUSES THE 6510 ÃÐÕ TO STOP EXECUTING THE CURRENT PROGRAM, SAVE THE REGISTERS ON THE STACK, AND BEGIN TO EXECUTE THE INTERRUPT CODE. ÓOME OF THE THINGS WHICH GET DONE DURING AN INTERRUPT INCLUDE THE KEYBOARD SCAN, AND UPDATING ÔÉ (THE SOFTWARE CLOCK). ×HEN THE INTERRUPT CODE IS FINISHED, AN ÒÔÉ INSTRUCTION IS EXECUTED, WHICH BRINGS THE INTERRUPT'S EXECUTION TO A HALT. ÔHE REGISTERS ARE RETRIEVED FROM THE STACK, AND THE CURRENT PROGRAM IN MEMORY CONTINUES TO EXECUTE ONCE AGAIN. ÉT WILL CONTINUE TO DO SO UNTIL THE NEXT INTERRUPT OCCURS, ABOUT 1/60 OF A SECOND LATER. ÔHE ABOVE IS WHAT HAPPENS IN A NORMAL Ã64 (THE Ã128 FOLLOWS THE SAME IDEA, BUT MORE EVENTS OCCUR DURING A Ã128 INTERRUPT). [ÅD. ÎOTE: ÉN ADDITION, THE Ã=128 GENERATES ITS INTERRUPTS VIA A SCREEN RASTER INSTEAD OF THE ÃÉÁ CHIP.] ÈOWEVER, YOU CAN CHANGE THE NORMAL COURSE OF EVENTS, AND CAUSE SOME CODE OF YOUR DESIGN TO BE ADDED TO THE NORMAL LIST OF EVENTS WHICH OCCUR EVERY INTERRUPT. ÓOME OF THE SIMPLE FAVOURITES INCLUDE FLASHING THE BORDER 60 TIMES PER SECOND. (ÎOTE THAT WE HAVE NOT BEGUN THE TOPIC OF RASTERS YET; THIS HAS NOTHING TO DO WITH RASTERS. ÔHAT DISCUSSION BEGINS AT THE NEXT HEADING.) ÈOW DO YOU CHANGE THE INTERRUPT'S NORMAL COURSE OF ACTION? ÉT'S RATHER SIMPLE. ÔHE Ã64 CONTAINS AN INTERRUPT ÖÅÃÔÏÒ AT LOCATIONS 788/9 WHICH IS 'JUMPED THROUGH' BEFORE THE ËERNAL ÒOM GETS A CHANCE TO EXECUTE ITS CODE. ÉF YOU CHANGE THIS VECTOR TO POINT TO ÙÏÕÒ CODE, AND MAKE THE END OF YOUR CODE POINT TO THE NORMAL ËERNAL LOCATION (WHERE THE INTERRUPT NORMALLY WOULD HAVE JUMPED TO, $ÅÁ31), AND YOU ARE CAREFUL NOT TO STEP ON ANYTHING, YOUR CODE WILL BE EXECUTED 60 TIMES PER SECOND. ÁN EXAMPLE IS IN ORDER: ; FLASHER ; ; THIS PROGRAM CAUSES THE BORDER TO FLASH 60 TIMES PER SECOND ; SETUP = * SEI ; DISABLE INTERRUPTS LDA #INTCODE ; DO THE SAME WITH THE HIGH BYTE STA 789 CLI ; RE-ENABLE INTERRUPTS RTS ; RETURN TO CALLER INTCODE = * INC $D020 ; CHANGE BORDER COLOUR JMP $EA31 ; EXIT BACK TO ROM ÔHE ABOVE IS AN EXAMPLE OF A VERY SIMPLE INTERRUPT ROUTINE. ÉF YOU WERE TO ASSEMBLE IT WITH AN ASSEMBLER, AND ÓÙÓ TO THE ÓÅÔÕÐ ROUTINE, YOU WOULD SEE YOUR BORDER FLASH 60 TIMES PER SECOND. ÙOU WILL NOTICE THE ÓÅÉ AND ÃÌÉ MACHINE LANGUAGE INSTRUCTIONS USED ABOVE. ÔHEY ARE VERY IMPORTANT. ×E DON'T WANT AN INTERRUPT OCCURRING IN BETWEEN THE ÓÔÁ 788 AND THE ÓÔÁ 789 INSTRUCTIONS. ÔHINK WHAT WOULD HAPPEN IF ONE DID: 788 WOULD HAVE BEEN MODIFIED, BUT 789 WOULD STILL BE POINTING TO THE HIGH BYTE OF THE ËERNAL ADDRESS. ÒESULT: THE INTERRUPT WOULD HAVE JUMPED TO HEAVEN KNOWS WHERE. ÙOU CAN BE VIRTUALLY GUARANTEED THAT IT WOULD ÎÏÔ BE POINTING TO A VALID PIECE OF INTERRUPT CODE. ÙOUR MACHINE WOULD CRASH. ÔHE ÓÅÉ INSTRUCTION TURNS INTERRUPTS ÏÆÆ, SO THAT THERE IS NO DANGER OF AN INTERRUPT OCCURRING DURING EXECUTION OF THE FOLLOWING ROUTINE. ÔHE ÃÌÉ TURNS THEM BACK ON. ÉF YOU FORGET TO TURN THEM BACK ON, AND ACCIDENTALLY LEAVE THEM OFF, YOUR KEYBOARD WILL FREEZE WHEN YOU RETURN TO BASIC, AND YOUR MACHINE WILL SEEM TO LOCK UP. ÔHE ABOVE WAS A VERY SIMPLE EXAMPLE. ÔHERE ARE MANY USEFUL THINGS WHICH CAN ALSO BE DONE ON AN INTERRUPT. É HAVE SEEN CODE WHICH PLAYED MUSIC IN THE BACKGROUND OF A RUNNING ÂASIC PROGRAM (IT PLAYED THE POPULAR .ÍÕÓ FILES). ÇÅÏÓ USES INTERRUPTS EXTENSIVELY TO CONTROL THE POINTING OF THE MOUSE, AND TO TRIGGER EVENTS. ÉNTERRUPTS ARE POWERFUL BEASTS, AND THE FOLLOWING CONCEPT CONCERNING RASTER INTERRUPTS SPECIFICALLY IS A PARTICULARLY USEFUL ANIMAL FOR SOME PEOPLE. ÔHE ÒASTER ---------- Á RASTER IS A LOOSELY USED TERM. ÉT REFERS TO AN INTERRUPT THAT IS TRIGGERED WHEN THE RAY GUN ON THE BACK OF YOUR MONITOR DRAWS A CERTAIN LINE ON THE VIDEO SCREEN. ÔHERE ARE MANY DIFFERENT SOURCES WHICH CAN CAUSE AN INTERRUPT. ÙOU ARE NOT LIMITED TO WHAT THE ÃÉÁ CHIP CAN DO. ÒASTERS DEPEND ON INTERRUPTS SPECIFICALLY GENERATED BY THE ÖÉÄÅÏ CHIP. ÙOU COULD MAKE THIS INTERRUPT CHANGE THE BORDER COLOUR OF THE SCREEN BELOW A CERTAIN SCREEN LINE. ×HEN THE SCREEN LINE YOU SPECIFIED GETS REDRAWN, THE INTERRUPT GOES OFF. ÙOUR CODE THEN QUICKLY CHANGES SOME MEMORY LOCATIONS TO CREATE A DIFFERENT VIDEO MODE OR EFFECT. ÙOU COULD CAUSE THE BOTTOM HALF OF THE SCREEN TO GETS IT'S CHARACTER DEFINITIONS FROM ANOTHER, DIFFERENT CHARACTER SET. ÏR, YOU COULD MAKE THE TOP 3/4 OF YOUR SCREEN EXIST IN HI-RES MULTI-COLOUR GRAPHICS, AND KEEP THE BOTTOM 1/4 OF THE SCREEN IN TEXT MODE. ÓOME FACTS ABOUT THE VIDEO SCREEN: IT GETS REDRAWN EXACTLY 60 TIMES PER SECOND. ÉT CONTAINS 200 SCAN LINES ON THE NORMAL 25*40 DISPLAY, NUMBERED 50 TO 250 OR THEREABOUTS (NOTE THAT THERE ARE MORE VISIBLE SCAN LINES THOUGH: THE TOP AND BOTTOM BORDERS, FOR EXAMPLE). ÔHE ACTUAL RE-DRAWING OF THE SCREEN IS SYNCHRONIZED TO THE ELECTRICAL POWER COMING INTO YOUR HOUSE, 60 ÈZ. ÔHAT'S WHY SOME PROGRAMS BEHAVE DIFFERENTLY WHEN RUN ON ÅUROPEAN MACHINES. ÔHE POWER IS DELIVERED AT 50 ÈZ OVER THERE. ×HY DO WE HAVE TO WORRY ABOUT A VIDEO INTERRUPT? ÉF THE SCREEN GETS REDRAWN 60 TIMES PER SECOND, AND REGULAR INTERRUPTS ALSO OCCUR AT 60 TIMES PER SECOND, WHY NOT SIMPLY PUT SOME CODE INTO THE REGULAR INTERRUPT TO DO WHAT WE WANT WITH THE SCREEN? ÂECAUSE THE TWO TYPES OF INTERRUPTS ARE NOT IN SYNC. ÎEITHER ONE OF THEM OCCURS ÅØÁÃÔÌÙ 60 TIMES PER SECOND, AND THE DIFFERENCES ARE ENOUGH TO MAKE IT NEXT TO IMPOSSIBLE TO GET COORDINATED ACTIVITY OF ANY KIND HAPPENING ON THE SCREEN. ×HEN WE USE THE VIDEO INTERRUPT, WE ËÎÏ× WE ARE AT A CERTAIN LINE ON THE SCREEN, AS BEING ON THAT LINE IS WHAT CAUSED THE INTERRUPT TO HAPPEN IN THE FIRST PLACE. ÓO, LET'S SUMMARIZE. ×E KNOW THAT REGULAR INTERRUPTS OCCUR 60 TIMES PER SECOND. ×E ALSO KNOW THAT THE VIDEO SCREEN GETS RE-DRAWN 60 TIMES PER SECOND, AND THAT WE CAN CAUSE AN INTERRUPT TO BE GENERATED WHEN A CERTAIN LINE GETS DRAWN ON THE SCREEN. ÏNE SLIGHT DRAWBACK TO ALL OF THIS IS THAT ÂÏÔÈ TYPES OF INTERRUPTS (REGULAR AND RASTER DRIVEN) TRAVEL THROUGH THE ÓÁÍÅ VECTOR (IE. ABOUT 120 INTERRUPTS PER SECOND, 60 OF ONE, AND 60 OF THE OTHER). ÙOUR CODE WILL HAVE TO CHECK AND SEE WHAT THE SOURCE OF THE INTERRUPT WAS, AND ACT ACCORDINGLY. ÏR WILL IT? ÔHE SYSTEM NEEDS AN INTERRUPT TO OCCUR 60 TIMES PER SECOND TO DO HOUSEKEEPING, AND USES THE ÃÉÁ CLOCK TO GENERATE THE INTERRUPTS. ×E WANT TO INTERRUPT EVERY TIME A CERTAIN SCAN LINE IS REACHED ON THE MONITOR, WHICH WILL ALSO JUST HAPPEN TO OCCUR AT 60 TIMES PER SECOND. ×E ALSO HAVE TO MAKE SURE THAT THEY DON'T INTERFERE WITH EACH OTHER. ÔHE REGULAR INTERRUPTS SHOULD BE SENT TO THEIR ÒOM DESTINATION, WHILE OUR VIDEO INTERRUPTS SHOULD GO TO OUR CODE, AND NO WHERE ELSE. ÉF BOTH ARE OCCURRING AT 60 TIMES PER SECOND, WHY NOT DO THE JOB OF THE SYSTEM ÒOM, AND OUR VIDEO CODE ON THE ÓÁÍÅ INTERRUPT? ×E KNOW THAT THE ÃÉÁ CHIP IS NOT GOOD FOR THIS; IT IS OUT OF SYNC WITH THE VIDEO IMAGE. ×HY NOT TURN ÏÆÆ THE ÃÉÁ INTERRUPT, ENABLE THE RASTER/VIDEO INTERRUPT, AND DO BOTH JOBS ON ONE INTERRUPT? ÔHEN WE WOULD HAVE AN INTERRUPT SIGNAL THAT OCCURS 60 TIMES PER SECOND, AND IS IN PERFECT SYNC WITH THE VIDEO IMAGE. ÔHAT'S EXACTLY WHAT WE'RE GOING TO DO. ÁSTUTE READS WILL NOTICE A SLIGHT FLAW IN THE ABOVE LOGIC. ÆOR SIMPLIFICATION PURPOSES, É DIDN'T GET INTO THE FACT THAT YOU WILL NEED Ô×Ï RASTER INTERRUPTS ÐÅÒ ÓÃÒÅÅÎ TO ACCOMPLISH ANYTHING USEFUL. ×HY TWO? ÂECAUSE ANY CHANGE TO THE VIDEO MODE YOU PUT INTO EFFECT 3/4 OF THE WAY DOWN THE SCREEN WILL HAVE TO BE UNDONE AT THE ÔÏÐ OF THE NEXT SCREEN UPDATE. ÉF YOU DECIDE TO MAKE THE TOP 3/4 OF THE SCREEN A HI-RES IMAGE, AND THE BOTTOM 1/4 TEXT, YOU NEED ONE INTERRUPT 3/4 OF THE WAY DOWN THE SCREEN TO CHANGE FROM HI-RES TO TEXT, BUT YOU NEED A ÓÅÃÏÎÄ ONE AT THE TOP OF THE SCREEN TO CHANGE BACK TO HI-RES FROM TEXT. ÓO, WE WILL NOW HAVE 120 INTERRUPTS GOING OFF EVERY SECOND TO ACCOMPLISH OUR VIDEO DESIRES, WITH 60 OF THEM WORKING A DOUBLE SHIFT, MAKING SURE THE SYSTEM INTERRUPT CODE GETS EXECUTED ALSO. ÒEMEMBER THAT WE ARE WORKING WITH A SPECIFIC EXAMPLE. ÔHERE IS NO REASON WHY YOU COULDN'T SPLIT THE SCREEN INTO Î DIFFERENT VIDEO MODES, AND HAVE (Î+1)*60 INTERRUPTS GOING OFF PER SECOND. ÁS LONG AS YOU KEEP YOUR CODE SHORT (SO YOUR INTERRUPTS DON'T TAKE TOO LONG, AND HAVE ANOTHER INTERRUPT OCCUR BEFORE THE CURRENT ONE IS DONE - MESSY), IT WILL WORK BEAUTIFULLY. ÓO FAR, THIS IS ALL TALK. ÌET'S WRITE A FEW SHORT CODE SEGMENTS TO ACCOMPLISH SOME OF THE FEATS WE'VE JUST DISCUSSED. ÔHE FIRST WE'LL DO IS A RE-HASH OF THE ONE PRESENTED ABOVE. ÉT FLASHES THE BORDER AGAIN. ÉT DOES NOT DO ANY MID-SCREEN CHANGES OF VIDEO MODES OR ANYTHING FANCY LIKE THAT, SO ONLY 1 INTERRUPT PER SCREEN IS REQUIRED (IE. 60 PER SECOND, NOT 120 ETC.). ÔHIS PROGRAM SIMPLY SHOWS THE SAME IDEA, BUT THIS TIME USING VIDEO INTERRUPTS AS THE SOURCE RATHER THAN THE ÃÉÁ. ÙOU PROBABLY WON'T NOTICE A DIFFERENCE DURING EXECUTION. ---------------------------------------------------------------------------- ; FLASHER - PART ÉÉ ; ; THIS PROGRAM CAUSES THE BORDER TO FLASH 60 TIMES PER SECOND ; THE SOURCE OF THE INTERRUPTS IS THE VIDEO CHIP ; SETUP = * SEI ; DISABLE INTERRUPTS LDA #$7F ; TURN OFF THE CIA INTERRUPTS STA $DC0D LDA $D01A ; ENABLE RASTER IRQ ORA #$01 STA $D01A LDA $D011 ; CLEAR HIGH BIT OF RASTER LINE AND #$7F STA $D011 LDA #100 ; LINE NUMBER TO GO OFF AT STA $D012 ; LOW BYTE OF RASTER LINE LDA #>INTCODE ; GET LOW BYTE OF TARGET ROUTINE STA 788 ; PUT INTO INTERRUPT VECTOR LDA #INTCODE ... RTS - ÒE-VECTORS THE INTERRUPT CODE TO THE NEW CODE. INC $D020 - ÃHANGES THE BORDER COLOUR. LDA $D019 STA $D019 - ÔHESE LINES CLEAR THE BIT IN THE INTERRUPT REGISTER WHICH TELLS THE SOURCE OF THE INTERRUPT (IN PREPERATION FOR THE NEXT). LDA #100 STA $D012 - ÔHIS LINE RESETS THE RASTER LINE TO GO OFF AT LINE NUMBER 100 AGAIN (SAME AS ABOVE). ÉT SHOULD BE RESET, SO THE NEXT INTERRUPT WILL KNOW WHAT LINE TO OCCUR ON. JMP $EA31 - ÅXIT BACK TO THE ËERNAL ÒOM. Á ÕSEFUL ÅXAMPLE ---------------- ÔHE FOLLOWING IS AN EXAMPLE OF A MORE SOPHISTICATED PIECE OF RASTER CODE. ÉT MAKES THE TOP HALF OF THE SCREEN BORDER WHITE, AND THE BOTTOM HALF BLACK. --------------------------------------------------------------------------- SETUP = * ; SOME EQUATES ÃÏÌÏÕÒ1 = 0 ÃÏÌÏÕÒ2 = 1 ÌÉÎÅ1 = 20 ÌÉÎÅ2 = 150 ; CODE STARTS SETUP = * SEI ; DISABLE INTERRUPTS LDA #$7F ; TURN OFF THE CIA INTERRUPTS STA $DC0D LDA $D01A ; ENABLE RASTER IRQ ORA #$01 STA $D01A LDA $D011 ; CLEAR HIGH BIT OF RASTER LINE AND #$7F STA $D011 LDA #ÌÉÎÅ1 ; LINE NUMBER TO GO OFF AT STA $D012 ; LOW BYTE OF RASTER LINE LDA #>INTCODE ; GET LOW BYTE OF TARGET ROUTINE STA 788 ; PUT INTO INTERRUPT VECTOR LDA # 1. ÉÎÔÒÏÄÕÃÔÉÏÎ ÔHIS ARTICLE DISCUSSES THE WELL-UNKNOWN ÆASTLOAD COMMAND OF THE 1571 AND 1581 DISK DRIVE ÂURST ÃOMMAND ÉNSTRUCTION ÓET. ÉF YOU LOOK IN THE BACK OF YOUR '71 (OR '81 É PRESUME) DISK DRIVE MANUAL, YOU WILL FIND THAT THE INFORMATION GIVEN ABOUT THE ÆASTLOAD UTILITY IS NOT EXACTLY ABUNDANT. ÔHE ÆASTLOAD COMMAND WAS INTENDED TO LOAD PROGRAM FILES INTO MEMORY FOR EXECUTION, BUT IT CAN BE USED JUST AS WELL FOR READING THROUGH SEQUENTIAL FILES THAT WOULD BE MUCH TOO LARGE TO LOAD INTO A SINGLE BANK OF INTERNAL MEMORY. ÔO MAKE USE OF THE ÆASTLOAD BURST COMMAND, É IMPLEMENT A WORD COUNTING UTILITY THAT WILL COUNT THE NUMBER OF LINES, WORDS, AND CHARACTERS IN A TEXT FILE ON A 1571 OR 1581 DISK DRIVE. ÔHE ADVANTAGE OF USING THE ÆASTLOAD COMMAND OVER REGULAR SEQUENTIAL FILE ACCESSING THROUGH THE KERNEL AND ÄÏÓ IS THAT THE ÆASTLOAD OPERATES ABOUT 3.5 TIMES FASTER ON BOTH DRIVES. 2. ×ÏÒÄ ÃÏÕÎÔÉÎÇ ÕÔÉÌÉÔÙ ÔO USE THE WORD COUNTING PROGRAM, ÌÏÁÄ AND ÒÕÎ IT LIKE A REGULAR ÂÁÓÉà PROGRAM. ÉT WILL ASK YOU FOR THE NAME OF A FILE. ÅNTER THE NAME IF IT IS ON DEVICE NUMBER 8, OR PUT A ONE CHARACTER PREFIX AND A ":" IF IT IS ON ANOTHER DEVICE. Á "B" MEANS DEVICE 9, "C" DEVICE 10, ETC. ÔHE FOLLOWING ARE EXAMPLES OF VALID NAMES: . FILENAME "FILENAME" ON DEVICE 8 . B:FILENAME "FILENAME" ON DEVICE 9 . A:FILENAME "FILENAME" ON DEVICE 8 ÔHE FILE MUST BE ON EITHER A 1571 OR 1581 DISK DRIVE; THE PROGRAM WILL NOT WORK WITH NON-BURST DEVICES. ÔHE PROGRAM WILL WORK WITH EITHER ÐÒÇ OR ÓÅÑ FILES, SINCE THE ÆASTLOAD COMMAND CAN BE TOLD NOT TO WORRY ABOUT THE FILE TYPE. É USE THE SAME DEFINITION OF A WORD AS THE ÕNIX "WC" COMMAND USES: A SEQUENCE OF CHARACTERS DELIMITED BY WHITESPACE, WHERE WHITESPACE IS DEFINED TO BE ÓÐÁÃÅ, ÔÁÂ, AND ÎÅ×ÌÉÎÅ (ÃARRIAGE ÒETURN) CHARACTERS. ÔO GET THE LINE COUNT, É SIMPLY COUNT THE NUMBER OF ÎÅ×ÌÉÎÅS. ÉF THE LAST LINE OF THE FILE DOES NOT END WITH A ÎÅ×ÌÉÎÅ CHARACTER, THEN THE COUNT WILL BE ONE LINE SHORT. ÔHIS IS THE SAME AS THE ÕNIX WC COMMAND TOO. Á PROPER TEXT FILE SHOULD HAVE ITS LAST LINE END WITH A ÎÅ×ÌÉÎÅ CHARACTER. ÏN MY ÊIFFYÄÏÓ-IFIED 1571 AND 1581, É AM ABLE TO ACHIEVE A WORD COUNTING SPEED OF 5,400 CHARS/SEC AND 6,670 CHARS/SEC, RESPECTIVELY. É AM NOT SURE HOW MUCH OF A DIFFERENCE ÊIFFYÄÏÓ MAKES, BUT É AM NOT WILLING TO RIP OUT THE ÒÏÍS TO CHECK. É TESTED USING A 318Ë FILE. 3. ÂÕÒÓÔ ÒÅÁÄ ÌÉÂÒÁÒÙ ÔHIS SECTION PRESENTS THE BURST READING LIBRARY THAT YOU CAN INCORPORATE INTO YOUR OWN PROGRAMS AND DESCRIBES HOW THE BURST COMMANDS WORK. ÔHE LIBRARY HAS THREE CALLS: . BURSTÏPEN ( .Á=ÄEVICE, .Ø=ÎAMEÌEN, BURSTÂUF=ÆILENAME ) : . BURSTÒEAD () : BURSTÂUF, BURSTÓTATUS, BURSTÂUFÃOUNT . BURSTÃLOSE () É DEFINE THREE COMMON STORAGE VARIABLES FOR USING THIS PACKAGE: "BURSTÂUF", "BURSTÓTATUS", AND "BURSTÂUFÃOUNT". "BURSTÂUF" IS A 256 BYTE AREA WHERE THE DATA READ IN FROM THE DISK DRIVE IS STORED BEFORE PROCESSING, AND IS LOCATED AT $0Â00. "BURSTÓTATUS" IS A ZERO-PAGE LOCATION THAT KEEPS THE STATUS RETURNED FROM THE BURST COMMAND SYSTEM. ÔHIS IS NEEDED BY THE USER TO DETECT WHEN THE END OF FILE HAS BEEN ENCOUNTERED. "BURSTÂUFÃOUNT" GIVES THE NUMBER OF DATA BYTES AVAILABLE IN "BURSTÂUF" AFTER AN OPEN OR READ OPERATION. ÉTS VALUE WILL BE SOMEWHERE BETWEEN 1 AND 254. Á FULL SECTOR CONTAINS 254 BYTES OF DATA AND TWO BYTES OF CONTROL INFORMATION. "BURSTÓTATUS" AND "BURSTÂUFÃOUNT" ARE DEFINED TO BE AT LOCATIONS $ÆÅ AND $ÆÆ, RESPECTIVELY. ÙOU ARE ALLOWED TO ALTER THE VALUES OF THE TWO VARIABLES AND THE DATA BUFFER BETWEEN CALLS, IF YOU WISH. ÆOR REASONS NOT COMPLETELY UNDERSTOOD, INTERRUPTS MUST BE DISABLED FOR THE ENTIRE COURSE OF BURST READING A FILE. É SUSPECT THIS IS BECAUSE THE ÉÒÑ SERVICE ROUTINE READS THE INTERRUPT MASK REGISTER OF ÃÉÁ#1, THUS CLEARING THE ÓERIALÄATAÒEADY FLAG THAT THE BURST READ ROUTINE WAITS FOR. ÁNYWAY, THE OPEN ROUTINE DOES A ÓÅÉ AND THE CLOSE ROUTINE DOES A ÃÌÉ, SO YOU DON'T HAVE TO DO THIS YOURSELF. ÉF AN ERROR OCCURS DURING THE EXECTION OF ONE OF THESE ROUTINES, IT WILL RETURN WITH THE CARRY FLAG SET AND WITH THE ERROR CODE IN THE .Á REGISTER (SAME AS THE KERNEL (YES, É KNOW THAT ÃOMMODORE LIKES TO CALL IT THE "KERNÁL")). ÅRROR CODES 0 TO 9 CORRESPOND TO THE STANDARD KERNEL CODES, ERROR CODE 10 MEANS THAT THE DEVICE IS NOT A BURST DEVICE, AND ERROR CODES 16 TO 31 CORRESPOND TO THE BURST CONTROLLER STATUS CODES 0-15. ÉF NO ERROR OCCURS, THE ROUTINES RETURN WITH THE CARRY FLAG CLEAR, OF COURSE. ÏNLY ONE FILE MAY BE OPEN AT A TIME FOR ÆASTLOADING, SINCE ÆASTLOAD TAKES OVER THE DISK DRIVE AND THE ENTIRE SERIAL BUS. ÅVEN REGULAR FILES CANNOT BE ACCESSED WHILE A FASTLOAD IS IN PROGRESS. ÔHUS, ÆASTLOAD IS NOT SUITABLE FOR ALL FILE PROCESSING APPLICATIONS, BUT IT WORKS VERY WELL FOR READING A FILE INTO MEMORY (LIKE FOR A TEXT EDITOR) AND FOR SUMMARIZATION OPERATIONS (LIKE WORD COUNTING). ÔHE BURST LIBRARY REQUIRES THAT THE KERNEL AND É/Ï SPACE BE IN CONTEXT WHEN IT IS CALLED. 3.1. ÂÕÒÓÔ ÏÐÅÎ ÔHE WAY THAT A BURST COMMAND IS GIVEN IS TO GIVE A MAGICAL INCANTATION OVER THE COMMAND CHANNEL TO THE DISK DRIVE. ÙOU CAN EITHER USE THE LOW-LEVEL SERIAL BUS CALLS (ÌÉÓÔÎ, ÓÅÃÎÄ, ÃÉÏÕÔ, AND ÕÎÌÓÎ) OR USE THE ÏÐÅÎ AND ÃÈÒÏÕÔ CALLS. É USED THE LOW LEVEL CALLS FOR A LITTLE EXTRA ZIP. ÔHE BURST COMMAND FORMAT FOR ÆASTLOAD IS GIVEN IN THE BACK OF YOUR DRIVE MANUAL: . ÂÙÔÅ \ BIT: 7 6 5 4 3 2 1 0 Ü ÖALUE . -------+--------+-----+-----+-----+-----+-----+-----+-----+------- . 0 Ü 0 Ü 1 Ü 0 Ü 1 Ü 0 Ü 1 Ü 0 Ü 1 Ü "Õ" . 1 Ü 0 Ü 0 Ü 1 Ü 1 Ü 0 Ü 0 Ü 0 Ü 0 Ü "0" . 2 Ü Ð Ü Ø Ü Ø Ü 1 Ü 1 Ü 1 Ü 1 Ü 1 Ü 159 . 3 - ?? Ü Ü . -------+--------------------------------------------------+------- WHERE "Ø" MEANS "DON'T CASE" AND "Ð" MEANS "PROGRAM". ÉF THE Ð BIT IS '0' THEN ONLY PROGRAM (ÐÒÇ) FILES CAN BE LOADED, AND IF IT IS '1' THEN SEQUENTIAL (ÓÅÑ) FILES CAN BE LOADED AS WELL. ÔHE PACKAGE AUTOMATICALLY SETS THIS FLAG FOR YOU. ÎOTE THAT YOU DON'T HAVE TO DO AN ÉNQUIRE ÄISK OR ÑUERY ÄISK ÆORMAT IN ORDER TO USE THIS COMMAND LIKE YOU HAVE TO DO WITH THE BLOCK READING AND WRITING COMMANDS. ÉF YOU WANT TO TRY GIVING THE INCANTATION YOURSELF, ENTER: ÏÐÅÎ1,8,15,"Õ0"+ÃÈÒ$(159)+"ÆÉÌÅÎÁÍÅ" (WHERE "ÆÉÌÅÎÁÍÅ" IS THE NAME OF SOME FILE THAT EXISTS ON YOUR DISK) ON YOUR 128 AND YOUR DISK DRIVE WILL SPRING TO LIFE AND WAIT FOR YOU TO READ THE FILE DATA. ÙOU CAN'T READ THE DATA FROM ÂÁÓÉÃ, SO TO CANCEL THE COMMAND: ÃÌÏÓÅ1 ÔHE "BURSTÏPEN" CALL OF THIS PACKAGE ACCEPTS THE NAME OF THE FILE TO BE LOADED AT THE START OF THE "BURSTÂUF" BUFFER, THE LENGTH OF THE FILENAME IN THE .Ø REGISTER, AND THE DEVICE NUMBER TO LOAD THE FILE FROM IN THE .Á REGISTER. ÔHE BURST COMMAND HEADER AND THE FILENAME ARE SENT TO THE DISK DRIVE AS DESCRIBED ABOVE. ÔHE OPEN COMMAND ALSO READS THE FIRST SECTOR OF THE FILE, FOR TWO REASONS. ÆIRST, THE STATUS BYTE RETURNED FOR THE FIRST SECTOR HAS SPECIAL MEANING. ÓTATUS CODE $02 MEANS "FILE NOT FOUND". ÔHE PACKAGE TRANSLATES THIS INTO THE KERNEL ERROR CODE. ÓECOND, AND MOST IMPORTANT, THERE IS A BIZARRE FEATURE (READ: "BUG") IN THE ÆASTLOAD COMMAND. ÉF THE FILE TO BE READ IS ONLY ONE BLOCK LONG, THEN THE NUMBER OF BYTES REPORTED FOR THE BLOCK LENGTH IS TWO BYTES TOO SHORT. ÔHE FOLLOWING TABLE GIVES THE NUMBER OF BYTES REPORTED AND THE NUMBER OF ACTUAL BYTES IN THE SECTOR: . ÁCTUAL Ü 4 Ü 3 Ü 2 Ü 1 Ü 0 Ü . ---------+---------+---------+---------+---------+---------+ . ÒEPORTED Ü 2 Ü 1 Ü 0 Ü 255 Ü 255 Ü ÔHIS IS WHERE É RAN INTO PROBLEMS WITH ÚED-128; THE LOGIC OF MY PROGRAM SCREWED UP ON A ZERO LENGTH. É HAVE CORRECTED THE PROBLEM HERE, THOUGH. ÔHIS BUG IS BIZARRE BECAUSE IT ONLY HAPPENS IF THE FIRST SECTOR IS THE ONLY SECTOR IN THE FILE. ÔHE REPORTED LENGTH FOR ALL SUBSEQUENT SECTORS IS CORRECT. ÎOTE ALSO THAT 255 IS REPORTED FOR LENGTHS OF BOTH 1 AND 0. ÔHIS IS BECAUSE THERE IS NO ACTUAL ZERO LENGTH FOR ÃOMMODORE FILES. ÉF YOU ÏÐÅÎ1,8,2,"ÅÍÐÔÙ" AND THEN IMMEDIATELY ÃÌÏÓÅ1 YOU GET A FILE WITH ONE CARRIAGE RETURN CHARACTER IN IT. ÔHE OPEN ROUTINE CALLS THE READ ROUTINE TO READ A SECTOR AND IF IT WAS THE ONLY SECTOR OF THE FILE, THE TWO ADDITIONAL BYTES ARE BURST-READ AND PUT INTO THE DATA BUFFER. ÎOTE THAT INCREMENTING THE REPORTED COUNT OF 255 TWICE GIVES THE CORRECT COUNT OF 1. ÁLSO INTERESTING IN THIS CASE IS THAT WHEN THE 1571/81 REPORTS THE 255, IT ACTUALLY TRANSFERS 255 BYTES OF DATA, ALL OF WHICH ARE BOGUS. ÉT SEEMS TO ME THAT THEY MADE THE 1581 BUG-COMPATIBLE WITH THE 1571 IN THIS RESPECT. ÔHE OPEN ROUTINE ALSO EXECUTES A ÓÅÉ FOR REASONS DISCUSSED ABOVE. ÔHE INFORMATION RETURNED BY THE OPEN CALL IS THE SAME AS WHAT IS RETURNED FOR THE "BURSTÒEAD" CALL DISCUSSED NEXT. 3.2. ÂÕÒÓÔ ÒÅÁÄ ÏNCE THE ÆASTLOAD COMMAND IS STARTED, THE DRIVE STARTS WAITING TO TRANSFER THE DATA TO YOU. ÔHE TRANSFER OCCURS SECTOR BY SECTOR, WITH EACH SECTOR PRECEEDED BY A BURST STATUS BYTE. ÔHE DATA IS TRANSFERRED USING THE SHIFT REGISTER OF ÃÉÁ#1 AND THE HANDSHAKING IS DONE USING THE ÓLOW ÓERIAL ÃLOCK LINE OF ÃÉÁ#2. ÔO RECEIVE A BYTE, YOU TOGGLE THE ÓLOW ÓERIAL ÃLOCK LINE AND WAIT FOR THE ÓHIFT ÒEGISTER ÒEADY SIGNAL FROM ÃÉÁ#1 AND THEN READ THE DATA VALUE FROM THE SHIFT DATA REGISTER. ÏNE OF THE CLOCK REGISTERS IN THE ÃÉÁ IN THE 1571/81 IS USED AS THE BAUD RATE GENERATOR FOR THE SERIAL LINE. É THINK THAT IT USES A DELAY OF 4 MICROSECONDS PER BIT, WHICH GIVES A BAUD RATE OF 250,000 (31.25Ë/SEC). ÉN MY EXPERIMENTATION, THE MAXIMUM BAUD RATE É HAVE EVER ACHIEVED IN REALITY IS 200,000 (25Ë/SEC). É READ IN MY 1571 ÉNTERNALS BOOK THAT THE 250,000 BAUD RATE CANNOT ACTUALLY BE ACHIEVED BECAUSE OF ELECTRICAL PROBLEMS THAT É DON'T UNDERSTAND. ÔHIS IS AN IMPORTANT DIFFERENCE BECAUSE THE DATA COMES FLYING OFF THE SURFACE OF THE DISK AT AROUND 30Ë/SEC AND IF THE SERIAL BUS WERE FAST ENOUGH, IT COULD BE TRANSFERRED TO THE COMPUTER AS IT IS BEING READ. ÓOME THINGS WOULD BE SO MUCH MORE CONVENIENT IF WHOMEVER CREATED THE UNIVERSE HAD THOUGHT TO MAKE LIGHT GO JUST A LITTLE BIT FASTER. ÔHE BURST HANDSHAKING PROTOCOL SLOWS THE MAXIMUM TRANSFER RATE DOWN TO ABOUT 16Ë/SEC. ÏF COURSE, THE DISK DRIVE HAS MORE THINGS TO KEEP ON TOP OF THAN JUST TRANSFERRING DATA, SO THE ACTUAL BURST THROUGHPUT IS LOWER THAN THAT: ABOUT 5.4Ë/SEC WITH MY ÊIFFYÄÏÓ-IFIED 1571 AND ABOUT 7Ë/SEC WITH A 1581. ÎOTE THAT YOU CAN PROBABLY INCREASE YOUR 1571'S BURST PERFORMANCE A BIT BY SETTING IT TO USE A SECTOR INTERLEAVE FACTOR OF 4, USING THE "Õ0>Ó"+ÃÈÒ$(I) BURST COMMAND. ÂY DEFAULT, A 1571 WRITES FILES WITH AN INTERLEAVE OF 6. ÁLL OF THE SECTORS BEFORE THE LAST ONE WILL CONTAIN 254 BYTES OF DATA AND THE LAST ONE WILL CONTAIN A SPECIFIED NUMBER OF BYTES, FROM 1 TO 254. ÔHE STATUS CODE RETURNED FOR THE LAST SECTOR IS VALUE $1Æ. ÉN THIS CASE, AN ADDITIONAL BYTE IS SENT BEFORE THE DATA BYTES THAT TELLS HOW MANY DATA BYTES THERE WILL BE. ÔHIS IS THE VALUE THAT IS BUGGED FOR ONE-SECTOR FILES AS DESCRIBED IN THE LAST SECTION. ÆOR THOSE WHO LIKE PICTURES, HERE ARE DIAGRAMS OF THE DATA TRANSFERRED FOR A SECTOR: . ÒÅÇÕÌÁÒ ÓÅÃÔÏÒ ÌÁÓÔ ÓÅÃÔÏÒ ÏÆ ÆÉÌÅ . +-------------------+ +--------------------+ . 0 Ü ÂURST ÓTATUS ÂYTE Ü 0 Ü ÂURST ÓTATUS = $1Æ Ü . +-------------------+ +--------------------+ . 1 Ü Ü 1 Ü ÂYTE ÃOUNT = Î Ü . ... + 254 ÄATA ÂYTES Ü +--------------------+ . 254 Ü Ü 2 Ü Ü . +-------------------+ ... Ü Î ÄATA ÂYTES Ü . Î+1 Ü Ü . +--------------------+ ÉF A SECTOR RETURNS A BURST STATUS CODE OTHER THAN 0 (OK) OR $1Æ (END), THEN AN ERROR HAS OCCURRED AND THE DISK DRIVE ABORTS THE TRANSFER, CLOSES THE BURST CONNECTION, AND STARTS THE DRIVE LIGHT BLINKING. ÔHE "BURSTÒEAD" CALL OF THIS PACKAGE READS THE DATA OF THE NEXT SECTOR OF THE OPENED FILE INTO THE "BURSTÂUF" AND RETURNS THE "BURSTÓTATUS" AND "BURSTÂUFÃOUNT" (BYTES READ). ÉN THE EVENT OF AN ERROR OCCURING, THIS ROUTINE RETURNS WITH THE CARRY FLAG SET AND THE TRANSLATED BURST ERROR CODE IN THE .Á REGISTER (SAME AS BURSTÏPEN). ×HEN THE LAST SECTOR OF THE FILE HAS JUST BEEN READ, THIS ROUTINE RETURNS WITH A VALUE OF $1Æ IN THE "BURSTÓTATUS" VARIABLE. 3.3. ÂÕÒÓÔ ÃÌÏÓÅ ÁFTER READING THE LAST DATA BYTE OF THE LAST SECTOR OF THE FILE, THE BURST CONNECTION AND IS CLOSED AUTOMATICALLY BY THE DISK DRIVE. ÔHE "BURSTÃLOSE" ROUTINE IS NOT NECESSARY FOR COMMUNICATION WITH THE DISK DRIVE, BUT IS PROVIDED FOR COMPLETENESS AND TO CLEAR THE INTERRUPT DISABLE BIT (ÃÌÉ) THAT THE OPEN ROUTINE SET TO PREVENT INTERRUPTS WHILE BURST READING.